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SNA in Perspective: 1992 

SNA was much in the news in 1992, with router vendors supporting SNA, LAN 
gateway vendors supporting APPC, and significant controversy over APPN. The 
major SNA networking themes in 1992 were: 

. • APPN • Multiprotocol participation 

• LAN/WAN integration ‘ Network management 

APPN is finally on all IBM platforms. The company invited other vendors to partic¬ 
ipate. The feedback was a requirement for more openness, and IBM has been 
responding. On the LAN/WAN front, we found SNA on routers, Ethernet, and frame 
relay as well as enhanced LAN-mainframe support on all of IBM's controllers. In 
the multiprotocol arena, we find TCP/IP also on all IBM platforms and extensive 
TCP/IP and SNA interaction. IBM’s networking blueprint is a vision for interoper¬ 
ability between applications, APIs, transports, and subnetworks of differing environ¬ 
ments—a far cry from the monolithic seven-layer protocol towers of yesterday. 

SNMP network management made large strides with the AIX NetView/6000 and 
LANfocus Management/2, but NetView made little progress in subarea SNA or 
APPN support. 

(continued on page 2) 


SNA Directions: 

1993 and Beyond 

In this article, we discuss SNA Perspective's projection of SNA network evolution 
during 1993 and beyond. Note the emphasis on beyond. Some of the networking 
directions we see IBM taking are clear now; others will evolve as 1993 unfolds and 
will probably-take clearer shape in 1994. 

We see several areas in which IBM will take significant steps in 1993 and beyond. 
Four of them carry forward our major themes of 1992. The last theme is an increas¬ 
ing trend toward alliances with other corporations and the industry in general. We 
touch on three: Novell, the CPI-C Implementor’s Workshop, and APPI. 

(continued on page 13) 


In this issue: 

SNA in Perspective: 

1992.1 

This was the year of 

“SNA and _/’ that is, 

SNA as it relates to every¬ 
thing around it. IBM net¬ 
working made many 
moves in 1992, especially 
toward openness, multi¬ 
protocol support, and 
decoupling applications 
from networking. We 
focus on APPN, LAN/ 
WAN integration, multi¬ 
protocol participation, and 
network management. 


SNA Directions: 

1993 and Beyond..1 

1993 is a make or break 
year for APPN. IBM must 
sell the industry on its 
advantages (which we 
believe it has) or APPN 
will be trampled under the 
TCP/IP juggernaut. We 
also examine IBM's efforts 
to integrate existing SNA, 
TCP/IP, NetBIOS, 
NetWare IPX, and OS I 
networks and Coherently 
manage the result. 

Architect's Corner: 
Plumbing Paradigm is 
Obsolete........18 

The network is usually 
described with a plumbing 
paradigm. Our architect 
posits this is not incorrect 
but is insufficient for 
today's networks. The 
network is an operating 
system, a resource 
manager, just like the 
APPC folks envisioned it. 
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Perhaps the most important word in the SNA vocab¬ 
ulary in 1992 was, ironically, TCP/IP. TCP/IP is 
showing up in a number of ways in “SNA” net¬ 
works: TCP/IP is increasingly coresident on main¬ 
frames with VTAM. TCP/IP sockets applications 
will be running over APPC/APPN and CPI-C appli¬ 
cations will be running over TCP/IP. SNA can be 
tunnelled in several ways through TCP/IP networks, 
and TCP/IP can also be carried across SNA back¬ 
bones. TCP/IP is discussed below under TCP/IP 
Pervasiveness. 

The second most important word for SNA was 
APPN. We rate it second only because it involved 
mostly announcements and statements of direction 
rather than shipped products. But these were signif¬ 
icant announcements and IBM made several moves 
to open APPN, as discussed below. 

The third word was multiprotocol integration, listed 
third for editorial reasons—-it connects the first two 
words and many more. The monolithic seven-layer 
networking towers seemed to split into three mix- 
and-match sets: a few standard APIs and session 
protocols, a few standard transport/network sets, a 
few standard LANs and WANs. The most thorough 
example of this trend was the networking blueprint, 
IBM’s strongest and clearest statement to date of its 
commitment to multivendor environments (and, 
some would say, commitment to reality). These 
issues, and multiprotocol implementations on IBM 
products and other vendor’s routers, are discussed 
below under Multiprotocol Participation and under 
LAN/WAN Integration. 

Network management is number one on many SNA 
users’ list of concerns. Most of the action in 1992 
was, again, in announcements and statements of 
direction rather than shipped products—but they 
were wide-ranging. IBM network management 
products included new release of Net View, a fully 
featured Simple Network Management Protocol 
(SNMP) manager on the RS/6000—A1X 
NetView/6000, a distributed version partner for it— 
Systems Monitor/6000, an OS/2-based LAN network 
management family—LANfocus Management/2, 
and enhanced LAN Network Manager. 


APPN 

During 1992, Advanced Peer-to-Peer Networicing 
(APPN) topped the news in SNA. There were two 
major trends: platform pervasiveness and openness. 
APPN network node and/or end node was finally 
announced for every major IBM platform. IBM 
also made several dramatic moves toward opening 
APPN to increase its acceptance in the multivendor 
networking community. Many statements of direc¬ 
tion were made for APPN network management 
support, but little was officially announced in prod¬ 
ucts. APPN has been positioned squarely as IBM’s 
pivotal networking integration architecture through 
the 1990s and beyond. 

Platform Pervasiveness 
The addition of full APPN nodes to VTAM has 
finally completed IBM’s strategic transition to sup¬ 
port peer-to-peer networking across all IBM’s SAA 
and AIX platforms, ten years after it was first dis¬ 
cussed and six years after it was first announced for 
the System/36. IBM announced in March that it 
would add APPN network node and end node to the 
mainframe. APPN will be part of VTAM 4.1, which 
will ship in the first half of 1993. 

Also announced in March 1992 was APPN support 
for: 

• 6611 multiprotocol router—statement of 
direction for network node 

• RS/6000—statement of direction for end node 
and network node in AIX SNA Services/6000 

• DOS and Windows—Networking Services/DOS 
as LEN node only, with APPC as well 

APPN is already on many of IBM’s other platforms: 
AS/400, OS/2 Communications Manager, 3174, and 
DPPX/370 (see Figure 1 on page 3). 

VTAM 4.1. ACF/VTAM Version 4 was shipped for 
testing to selected customers by the end of 1992. 
General availability is expected about the middle of 
1993. 

VTAM APPN support includes APPN end node and 
network node on VTAM Version 4 for MVS and a 
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statement of direction for VM. With its NCPs, a 
VTAM can be configured as a composite network 
node. A composite network node provides to the 
APPN network the appearance that a given VTAM 
and all its associated NCPs (at release 6.2) are one 
node. A VTAM APPN network node need not own 
NCPs, however, it is a configuration option. A 
VTAM APPN end node never includes NCPs, 
although it can attach to NCPs owned by another 
VTAM network node. An NCP can only be part of 
composite network node, never an APPN node by 
itself. 

Viable dependent LU support over APPN is 
provided in VTAM 4.1, which will support LUs in 
nodes logically adjacent to their boundary function 
nodes. A future release will implement the depen¬ 
dent LU requester/server model and support depen¬ 
dent LUs arbitrarily connected to an APPN network, 
as discussed in the SNA Directions article in this 
issue. 

Openness 

IBM originally envisioned APPN as its own proto¬ 
col for IBM systems, with OSI and TCP/IP to serve 
for interconnection between systems from IBM and 
other vendors. IBM felt this position would be suc¬ 
cessful since it will be easier to migrate from sub- 
area SNA to APPN rather than to TCP/IP and APPN 
offers several technical advantages over TCP/IP. 


However, many of its customers are insisting on 
multi vendor standards across the board and would 
still choose TCP/IP if APPN is not available from 
several vendors. These vendors, in turn, indicate a 
reluctance to implement APPN since TCP/IP is rela¬ 
tively inexpensive, pervasive, publicly developed, 
and in the public domain. Feedback from these 
users and vendors convinced IBM to increasingly 
open APPN during 1992. 

Several of these vendors, in fact, formed the 
Advanced Peer-to-Peer Internetworking (APPI) 
Forum in August with the goal of developing speci¬ 
fications to support APPN end nodes and LEN 
nodes overTCP/IP not using APPN directory ser¬ 
vices or routing and topology protocols. (See 
“APPI: The Product and the Protest,” SNA 
Perspective, December 1992.) 

There are several degrees of openness: published 
interfaces, source code licensing, published specifi¬ 
cations, free/nominal fee patent rights, published 
development plans, open industry development/par¬ 
ticipation, and open ownership. IBM has turned up 
the heat on openness many degrees in 1992: 

• Published several APPN-related interfaces and 
protocols. It published APPN end node 

• Proposed multiprotocol transport networking 
(MPTN) to X/Open 



• Decided to propose several APPN 
interfaces to the Internet Engineering 
Task Force (IETF) 

• Is licensing APPN network node source 
code (to be shipped in first quarter 1993 

• Agreed to publish network node specifica¬ 
tions by first quarter 1993, though it has 
not announced patent right lees 

• Held APPC/APPN conferences for 
platform and application developers 

These are all significant steps toward making 
APPN more open and available in a multivcn- 
dor environment. However, to counter the 
market momentum of TCP/IP, I BM may need 
to make further moves to foster APPN accep¬ 
tance, as we discuss in the SNA Directions 
article in this issue. 
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For more details on these APPN issues, see the fol¬ 
lowing SNA Perspective articles “APPN Strategy 
Today” (January), “Enterprise Network Management 
Part II: SNA Peer-to-Peer” (February), “APPN: 

Key in IBM’s Networking Blueprint” (April), 
“APPN Insights and Design Clues” (April), “Users 
Plan for New Technologies: SNA over Routers and 
APPN” (October), “Old Apps, New Nets— 
Dependent LUs Across APPN” (November), and 
“APPI: The Product and the Protest” (December). 


LAN/WAN Integration 

IBM announced its networking blueprint in March 
(see “Blueprint to Integrate the Architectures,” SNA 
Perspective, August 1992). One of its major objec¬ 
tives is to integrate LAN, WAN, network, transport, 
transaction processing, and API technologies to 
enable applications running in diverse processing 
platforms and operating environments to intercon¬ 
nect and share resources coherently. This should 
happen regardless of underlying differences in appli¬ 
cation session services, network transport and rout¬ 
ing algorithms, and network connectivity interfaces. 

Major developments in 1992 in LAN/WAN integra¬ 
tion in SNA were: 

• SNA support on multiprotocol routers, 
including the IBM 6611 announced in January 
and shipped in September and the IBM 
RouteXpander/2 announced in September 

• SNA support over emerging subnetwork 
technologies such as SMDS, ISDN, and, 
particularly, frame relay 

• Increased IBM support for Ethernet, including 
shipment of Ethernet for the 3745, statement of 
direction for Ethernet on the 3174, and general 
purpose Ethernet adapters for the PS/2. 

• ESCON channel and enhanced token ring 
support for the 3745 communication controller 

• Mixed-media mullilink transmission groups 

• Enhanced support for token ring, Ethernet, and 
FDDl integration including the IBM 8250 


SNA Support on Multiprotocol Routers 

Since early 1991, multiprotocol router vendors 
began announcing support for SNA over TCP/IP 
networks. Figure 2 (see page 5) shows several 
approaches that have evolved for supporting SNA, 
including source route bridging, SDLC passthrough, 
SDLC conversion, and SDLC and LLC2 local 
termination. 

6611. The long-awaited IBM 6611 multiprotocol 
bridge/router was announced in January and, after a 
few delays, shipped in September. With routable 
support for IP, XNS, IPX, DECnet, and AppleTalk, 
plus source route bridging, the product made a 
respectable entry into this market. But significant 
holes exist—no SNA routing (tunnels but no 
routes), limited Ethemet/802.3 support, weak 
SNMP MIB support, weak X.25 support, and weak 
bridging function. The 6611 has many features tar¬ 
geted at existing SNA networks that can be grouped 
under the term data link switching 

RouteXpander/2, announced in September, is 
low-end OS/2 based device driver software that 
supports frame relay, source route bridging, and 
multiprotocol routing. It supports up to 200 frame 
relay logical links over a single physical link. 
RouteXpander/2 is a relatively simple product but it 
is valuable because it takes advantage of existing 
communication protocols on the PS/2, such as IP, 
APPN, peripheral or subarea SNA, NetBIOS, and 
IPX; they do not have to be changed since connec¬ 
tions appear to be bridged over token ring when 
they are actually routed through a WAN via frame 
relay. SNA Perspective believes that RouteXpander/2 
is an intriguing product and that its capabilities will 
be added to other products. 

Ethernet 

Considerable activity was seen from IBM in the 
Ethernet arena in 1992. 

3745. In August, IBM finally shipped NCP 6.1 and 
the Ethernet adapters that it supports. The 3745 
Ethernet adapters support only TCP/IP traffic, 
though, and not SNA traffic. SNAlink was ported 
to the 3745 from the host, so 3745s with Ethernet 
adapters can tunnel TCP/IP traffic across the SNA 
backbone without routing it through a host. 
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3174. Several 3270 controller vendors have offered 
Ethernet adapters for some time. Since IBM added 
TCP/IP support on the 3174 in 1991, it was not sur¬ 
prising when IBM made a statement of direction in 
1992 to add Ethernet to it as well. 

PC Adapters. In September, IBM unveiled its own 
line of general-purpose PC adapters for Ethernet, 
which underscore its involvement in TCP/IP. 

Frame Relay and Other 
Emerging Subnetworks 

Several technologies are emerging to support the 
future need for high-speed LANs and WANs. IBM 
has kept a low profile on the switched multimegabit 


data service (SMDS), probably because it is a public 
service, while frame relay can be implemented in 
both public and private networks, which means IBM 
could still control the backbone. Broadband inte¬ 
grated services digital network (ISDN) and the 
asynchronous transfer mode (ATM) which will sup¬ 
port it are longer-term emerging technologies. 

Frame relay represents a new packet-switching 
focus to provide higher speed technology for infor¬ 
mation systems that are increasingly time sensitive. 
Frame relay is a logical step for IBM in light of the 
past connection between IBM equipment and X.25, 
a technology that frame relay seeks to replace. A 
significant benefit of frame relay is that, unlike 
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X.25, it can natively support any protocol, such as 
SNA, TCP/IP, and nonroutable protocols such as 
NetBIOS or Novell’s IPX encapsulated in IP. 

LAN-Mainframe Support 

ESCON. In September, IBM announced several 
enhancements for the 3745. The most significant 
was the 3746-900 expansion frame for 3745 models 
210, 310,410, and 610, which adds ESCON chan¬ 
nel and enhanced token ring support. IBM plans to 
support more ESCON and high-performance token 
ring adapters on the 3746-900 and to provide both 
the new ESCON and high-performance token ring 
adapters for the smaller 3745-170. The addition of 
ESCON to the communication controller increases 
speed and distance for LAN-mainframe connections 
and allows connection to up to eight hosts through 
one ESCON adapter and an ESCON director. 

Token Ring. The enhanced token ring support on 
the 3746-900 offers increased performance and 
additional slots for a 3745 for token ring and 
Ethernet. 

3172. The new 3172-3 offers increased perfor¬ 
mance at a lower price for host access through SNA 
and TCP/IP over Ethernet, token ring, and FDDI. 
The 3172 is being licensed by other vendors as well, 
such as Bus-Tech which is adapting the 3172 with 
software to support NetWare and IPX. 

Mixed-media Multilink Transmission Groups 

This new feature of NCP 6.2 provides a new means 
for defining transmission groups. Previously, multi¬ 
ple SDLC links between two 3745s could be associ¬ 
ated as a single transmission group, providing a 
means of load balancing and back-up. However, a 
token ring network had to be defined in a separate 
transmission group from SDLC links, and token rings 
were limited to one network per transmission group. 
Frame relay networks were similarly limited. Now 
multiple SDLC, token ring, or frame relay networks 
can be associated in a single transmission group. 

LAN Integration: The 8250 Multiprotocol Hub 

Token ring, Ethernet, and FDDI emerged as the per¬ 
vasive LAN technologies supporting SNA and other 
protocols, with frame relay and SMDS emerging as 
WAN subnetwork contenders. 


IBM’s entry into the multiprotocol intelligent hub 
market is the 8250. This backbone “LAN in a box” 
includes several multiport modules for Ethernet (in 
various media types including optical fiber), token 
ring, and FDDI, as well as modules that provide 
LAN management and SNMP for the system. Other 
modules permit interconnection via Ethernet bridg¬ 
ing. IBM announced in July 1992 an agreement to 
work with Chipcom Corporation on future products 
and the 8250 is the first result of this cooperation 
between the two companies. A related hub manage¬ 
ment program runs on the RS/6000. 

References 

For more details on LAN/WAN integration, refer to 
the following SNA Perspective 1992 articles: “3174 
Part II: Hard Hit by Gateways” (February), “LAN 
Network Manager Update” (June), “Animal, 
Vegetable, or Mineral: The 3172 Interconnect 
Controller” (July), “Data Link Switching on the 
IBM 6611” (August), “Optimizing SNA over 
Internetworks” (September), “SNA and the Future 
of X.25” (September), “The Rites of Autumn: 

IBM’s September Announcements” (3745, frame 
relay, transmission groups, RouteXpander/2) 
(October), “Sprucing Up Your 3270 Controller” 
(December). 


Multiprotocol Participation 

Users increasingly need access to resources across 
multiple networks, and the applications they use 
need to share data. This creates the need for multi¬ 
protocol internetworking. The major thrusts for 
SNA multiprotocol participation we saw in 1992 are 
SNA on multiprotocol routers, IBM’s networking 
blueprint, and TCP/IP pervasiveness. 

Networking Blueprint 

The IBM networking blueprint was introduced in 
March 1992 as a strategy to support the coexistence 
of a wide range of application interfaces over a 
diverse set of networking architectures through a 
common set of transport semantics. It was designed 
to integrate diverse LAN, WAN, and transaction 
processing technologies, to support multiprotocol, 
multivendor, and multimedia elements, to enable 
users and their applications to interconnect across 
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diverse environments, to support client/server com¬ 
puting in a consistent way for end users, to exploit 
high-speed, high-bandwidth technology and ser¬ 
vices, and to provide comprehensive, architecture- 
independent management. 

Common transport semantics, as shown in Figure 3, 
is an interface that rides on top of layer 4 of the OSI 
reference model. MPTN is a significant part of 
IBM’s plan for the common transport semantics 
component in the networking blueprint. MPTN is 
IBM’s proposed extension to the X/Open Transport 
Interface (XTI). XTI, in turn, is an X/Open 
specification for mapping between TCP/IP and OSI, 
and MPTN is designed to extend this mapping and 


compensation to APPN SNA and NetBIOS. The 
significance of MPTN is that it provides an “any-to- 
any” connection. 

However, individual implementations based on 
MPTN will probably be single elements (e.g., one 
API over one transport network) rather than a sin¬ 
gle, massive protocol interface. MPTN may be 
implemented either on an end system as a server (so 
that a single application can run, unmodified, and be 
accessed from systems over several transports) or as 
a gateway in a separate node on the network. End 
users and their applications are unaware of the pro¬ 
tocol or collection of protocols selected to transport 
their data across the network. 


IBM has discussed three products 
that will be implemented as part 
of common transport semantics: 
TCP/IP sockets applications over 
APPG/APPN (informally referred 
to as SNAckets), CPI-C applica¬ 
tions over TCP/IP, and NetBIOS 
applications over APPN SNA 
(informally called SNAbeui). 

Another integration product intro¬ 
duced in 1992 (which is not part 
of common transport semantics) 
is the IBM CICS-sockets inter¬ 
lace. An application on a TCP/IP 
network can access a Customer 
Information Control System 
(C1CS) application completely . 
through TCP/IP with no VTAM 
involvement at all. 


TCP/IP Pervasi veness 

Although only a few years ago, 
IBM thought of TCP/IP as a tran¬ 
sition step to OSI, the company 
now considers SNA, OSI, and 
TCP/IP all to be strategic archi¬ 
tectures and is moving fast to 
integrate its TCP/IP products with 
SNA, as well as with network 
management—continuing its 
coordination of Net View and 

Figure 3 


IBM Networking Blueprint 
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SNMP. IBM is betting heavily on APPN, but it is 
not missing out on the popularity of TCP/IP. 

IBM is finding some user confusion and resistance, 
however. Although IBM has offered TCP/IP on 
VM and the PS/2 since 1987, users are not yet used 
to IBM and TCP/IP in the same sentence. For 
example, a study by Infonetics Research of San 
Jose, California, indicates that users are reluctant to 
purchase a multiprotocol router from IBM. On the 
other hand, users of IBM TCP/IP on the host that we 
have talked to indicate that they are pleased with the 
products in spite of some overhead and performance 
issues. 

TCP/IP on all platforms. IBM offers TCP/IP on 
all its strategic platforms: VM, MVS, AS/400, and 
OS/2, as well as for DOS and Windows and as a 
native element of its AIX products: AIX/370, AIX 
for RS/6000 and AIX for the PS/2. In fact, IBM has 
a broader range of TCP/IP offerings than any other 
vendor and the feature set is quite extensive. New 
versions or releases of most of these were announced 
in 1992. Many other vendors also offer TCP/IP on 
most of these platforms or as outboard gateways 
between TCP/IP networks and an SNA host. 

TCP/IP over SNA. Most readers know that IBM 
and other vendors offer several products for sup¬ 
porting SNA over TCP/IP (discussed above). 
However, IBM also supports TCP/IP over an SNA 
backbone with SNAlink, which runs on the host and 
was added in 1992 to the 3745. 

3172 TCP/IP offload. During 1992, IBM added 
TCP/IP Offload to the 3172. TCP/IP Offload is an 
alternative to the native interconnect controller pro¬ 
gram and runs under OS/2. With TCP/IP Offload, 
the TCP/IP processing can be handled outside the 
mainframe, which frees it up for applications and is 
also more efficient. 

References 

For more details on multiprotocol participation, see 
the following SNA Perspective articles: “IBM’s 
Leading Communication APIs Face Off: CPI-C and 
APPC” (March) “IBM Makes Partners of SNA and 
OSI” (March), “Integrating TCP/IP into SNA” (Part I: 
May, Part II: June, Part III: July), “CPI-C Part II: 


IBM’s Strategic API” (May). “Blueprint to Integrate 
the Architectures” (August), “Optimizing SNA over 
Internetworks” (September), “Users Plan for New 
Technologies: SNA over Routers and APPN” 
(October), “APPI: The Product and the Protest” 
(December). 


Network Management 

The beginnings of true integrated network manage¬ 
ment were seen in 1992 from IBM. NetView 2.2 
can manage SNA, TCP/IP, and OSI networks. AIX 
NetView/6000 manages SNMP and CMIP networks 
and systems, can communicate with NetView 
through the AIX NetView Service Point and can 
convert SNMP traps into NetView alerts. Systems 
Monitor/6000 can distribute several functions of 
NetView/6000. (We would like to see a similar 
“skinny NetView” for the SNA arena.) LANfocus 
Management/2 can manage SNMP and CMIP LAN 
networks and can also coordinate with NetView. 
LAN Network Manager will have SNMP agent as 
well as CMIP support. 

IBM network management product announcements 
in 1992 included: 

• A new release of NetView 

• A fully featured Simple Network Management 
Protocol (SNMP) manager on the RS/6000— 
AIX NetView/6000 

• A distributed version partner for it— 

Systems Monitor/6000 

• An OS/2-based LAN network management 
family—LANfocus Management/2 

• An enhanced LAN Network Manager 

AIX NetView/6000 

IBM AIX NetView/6000, an SNMP manager based 
on Hewlett-Packard’s Open View, replaced AIX 
Network Manager/6000 in early 1992. It provides 
network management for TCP/IP devices with 
SNMP agents including the 6611 router. These 
agents are found extensively in environments such 
as Unix and LANs. AIX NetView/6000 also moni¬ 
tors all IP addressable devices. 
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Significant features included its OSF/Motif-based 
graphical user interface, a dynamic network discov¬ 
ery and mapping capability, and SNMP fault, per¬ 
formance, and configuration management features. 
As shown in Figure 4, AIX Net View/6000 can com¬ 
municate with host-based Net View through the AIX 
NetView Service Point. 

A new version of Net View/6000 was announced in 
1992 which included even more functionality, with 
several new features and functional responsibilities. 
NetView/6000 Version 2 Release 1 offers a new 
graphical user interface based on X Windows and 
Motif. The product can now manage OSI as well as 
SNMP, and supports three industry-standard appli¬ 
cation programming interfaces (APIs)—-X/Open 
Management Protocol, the Camegie-Mellon SNMP 
API, and the End User Interface API from Hewlett- 
Packard—as well as an IBM API. 

AIX Systems Monitor/6000 

Distribution of the management function will also 
be improved with the announcement of a program 
called Systems Monitor/6000. In essence, this pro¬ 
gram runs on distributed RS/6000s in association 
with one RS/6000 running NetView/6000. Systems 
Monitor/6000 collects a range of user-definable data 
on its RS/6000 and the LAN segment to which it is 
attached and provides that information selectively, 
through user-definable filters and thresholds, to AIX 


NetView/6000. The data gathered can range from 
the LAN to the application level. The program also 
allows for the automation of some management 
functions, responding automatically to a set of pre- 
established conditions. 

With Systems MonitOr/6000, the central manage¬ 
ment station is freed from the task of collecting all 
the data—only that data that the network manager 
will need/want will actually be provided. AIX 
NetView/6000 still has provides the status of the 
network and the graphical display of the networic. It 
also serves to configure the Systems Monitor/6000s 
that report to it. But with Systems Monitor/6000, 
the AIX NetView/6000 node is significantly 
removed from handling information that is 
unneeded or unwanted. 

LANfocus Management/2 

LANfocus Management/2 is an OS/2-based, 

System View-compliant LAN distributed systems 
management family which was alluded to all year 
by IBM and finally announced in October. The 
LANfocus family consists of several elements: 
LANfocus Manage/2 is the basic component. 
LANfocus Monitor is for gathering statistics. 
LANfocus Fix/2 is for problem detennination and 
handling. LANfocus Start/2 is for configuration. 
LANfocus NetView Tie/2 is for optional communi¬ 
cation with host-based NetView. LANfocus View/2 
is the graphical user interface. LANfocus Agents 

will reside in managed systems. Only 
a few of these elements were actually 
announced; the others are statements 
of direction. 

The first elements of LANfocus will 
ship in the second quarter of 1993 and 
several components will probably not 
ship until sometime in 1994. 

IBM has not specifically discussed 
the relationship between the new 
LANfocus Managcment/2 and its 
LAN Network Manager or LAN 
Management Utilities (LMU). 
However, it appears that the latter two 
will act as an element manager for the 
former, managing selected elements. 


NetView and NetView/6000 Communication 

SNA TCP/IP 
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RS/6000 
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How Did We Do In Forecasting 1992? 



In the December 1991 issue of SNA Perspective, 
we made some predictions about directions we 
thought IBM networking would and should take in 
the coming year. Let’s take a look at what actually 
happened. 

Online Transaction Processing 

• IBM will continue to enhance CICS to provide a 
wide range of online transaction processing 
solutions. 

Done. Major announcement in September. 

• CICS API will be enhanced to run with AS/400 
and AIX. 

Yes, and also to OS/2. CICS can run now on 
MVS, VM, VSE, AS/400, AIX, and OS/2. 

• CICS data types will include: 

• A Resource Manager interface for 
non-IBM data. 

Done. 

• Support for compound document data types 
with multiple Object Content Architectures. 

Yes. a) continuing evolution of Modified 
Object: Document Content Architecture 
(MO:DCA) b) IBM and Apple joint companies, 
Telligent and Kaieida, defining products to 
support vendor independent multimedia 
document management. 

• Possible support for X/Open data types. 
Unclear. 

’ IBM must enhance remote unit of work for two- 
phase commits in a distributed, segmented rela¬ 
tional database. 

Not yet. (Expected in 1993.) 

• IBM will add distributed unit of work to SAA CPI. 
Not done. (Expected in 1993.) 


• The networking interface for all affected applica¬ 
tions will be based on CPI-C and LU 6.2. 

Yes. IBM made abundantly clear during 1992. 

• CICS appears to be a strong candidate for 
development of an end-user API that would be 
transparent to the underlying IBM strategic SAA 
or AIX platform. 

Yes. 

APPN Enhancements 

• IBM should and likely will extend APPN network 
node logic to VTAM and to NCP in 1992. 

This was done in March for VTAM 4.1 and in 
September for NCP 6.2. 

• Upon rollout of NCP Version 6, it will include 
APPN network node and end node. 

Instead of adding APPN to the already- 
announced NCP 6.1, it was added to NCP 6.2. 

• IBM will announce ACF/VTAM Version 4 during 
1992, which will include APPN. 

Yes. Announced in March. 

• NetView must track APPN changes. IBM will 
incorporate APPN capability into NetView during 
1992. 

Some, but not enough. Many statements of 
direction to be filled in 1993. 

• IBM will publish an APPN network node format 
and protocol language document or perhaps 
publish under license. 

IBM said it was going to license it then said it 
was going to publish it. It will be published in 
the first quarter of 1993. 

• APPN network node will be incorporated into 
SAA CCS Network Services. 

Announced during 1992. 
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How Did We Do In Forecasting 1992? 

(continued) 


• APPN will evolve into a high performance rout¬ 
ing scheme to address requirements for OLTP 
and multigigabit LANs and metropolitan area 
networks (MANs). 

Long term, we still believe this will happen. IBM 
has started discussing high-performance routing 
(HPR), with a connectionless network protocol, 
that will be part of APPN+. 

Multiprotocol APIs 

• IBM will emphasize development of TCP/IP net¬ 
worked application solutions to the same extent 
as, if not greater than, their OSI solutions. 

Absolutely (described in the three-part series of 
articles in the May, June, and July issues of 
SNA Perspective ). 

• IBM will evolve a meta-architecture wherein 
applications and users will have access to appli¬ 
cations via a high-level, platform-independent 
API which makes transparent the underlying 
SNA, OSI, or TCP/IP application and network 
services. 

The meta-architecture is the networking blue¬ 
print. 


• IBM will architect additional SAA/OSI APIs for 
transaction processing, messaging, file process¬ 
ing, database processing, device streams, dis¬ 
tributed processing, graphical design, 
systems/network management, object-document 
interchange, and job processing. 

IBM did add message queueing and RPC as 
part of the networking blueprint. 

• SAA/OSI APIs will likely be extended during 
1992 and beyond to incorporate TCP/IP. 

This is essentially what the networking blueprint 
did. 

Multiprotocol Routers 

• The announcement of the multiprotocol router is 
now likely in January 1992. 

Yes. Announced in January. 

• The first version will ship early in 1992. 

Yes. It shipped in September. 

• APPN will be added later in 1992. 

APPN will be added in first quarter 1993. m 


LAN Network Manager 

LAN Network Manager 1.1 finally shipped in 
December. This version includes a graphical repre¬ 
sentation of IBM’s 8230 token ring hub and 8250 
multiprotocol hub, a new event filter, and support 
for Heterogeneous LAN Management, IBM’s LAN 
management standard for token ring and Ethernet 
which was developed in conjunction with 3Com. 
(See “LAN Network Manager Update’’ in SNA 
Perspective, June 1992.) 


In September, IBM announced LAN Network 
Manager 1.2, which also shipped in December. It is 
not really an enhanced release but is an alternative 
to LAN Network Manager 1.1 for different graphics 
environments. 

According to a September statement of direction, 
IBM will add an SNMP agent to a future release of 
LAN Network Manager pennitting it to communicate 
with NetVicw/6000 and any other SNMP monitor. 
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NetView Service Point and 
Performance Monitor 

A new release of AIX NetView Service Point adds 
LU 6.2 communication to NetView. A new release 
of NetView Performance Monitor includes frame 
relay, Ethernet, and LAN segment support. 

References 

For more details on SNA network management 
products, issues, and trends, refer to the following 
1992 SNA Perspective articles: “Enterprise Network 
Management Part I: The SNA Subarea” (January), 
“Enterprise Network Management Part II: SNA 
Peer-to-Peer” (February), “LAN Network Manager 
Update” (June), and “The Rites of Autumn: IBM’s 
September Announcements” (October). 


Miniaturization 

SNA Perspective also noted a mini-trend for in 
1992—miniaturization. IBM has provided SNA 
support for laptop PCs—through adapters and asyn¬ 
chronous SNA (SNA-A). In September, IBM 
announced credit-card-sized adapters, conforming 
to the personal computer memory card interface 
adapter (PCMCIA) industiy standard, for token 
ring, Ethernet, and 3270. 

During 1992, IBM released several products that 
implement SNA-A, which allows them to use the 
less expensive and more ubiquitous asynchronous 
modems rather than synchronous modems. This is 
particularly helpful for the portable PC user who has 
SNA traffic to send. 


Summary 

Despite all the controversy regarding APPN in 
1992, it cannot be called the year of APPN. It could 
be called the year of APPN promise—a promise that 
must be fulfilled in 1993. 

LAN/WAN integration in 1992 was extensive in 
1992, including SNA support on multiprotocol 
routers and frame relay, LAN-mainframe enhance¬ 
ments to the 3745, 3174, and 3172 for SNA and 


TCP/IP. mixed-media multilink transmission 
groups, and LAN integration in the 8250 hub. 

Multiprotocol participation was the name of the 
game for many participant. IBM now tells its story 
as the networking blueprint and its common trans¬ 
port semantics. Although it was unveiled in March, 
no products based on the common transport seman¬ 
tics were announced in 1992. Based on the blue¬ 
print’s strategic importance, we expect product 
announcements early in 1993. 

The important trend the networking blueprint epito¬ 
mizes is the collapse of the monolithic seven-layer 
architecture tower: SNA or TCP/IP Or OSI from top 
to bottom. Instead, it will be like the children’s 
books with multiple pages to mix and match for 
faces, torsos, legs, and feet. We could see “SNA 
applications” (e.g. CICS) with “TCP/IP APIs” (e.g., 
sockets) running over “OSI transport” (e.g., TP4 
and CLNP) on an “SNA data link” (e.g., token ring). 
Not all the combinations will be implemented in a 
single massive meta-architectural implementation, 
but then not all nor even most of the combinations 
will be needed. But hopefully, in 1993 and beyond, 
the chosen combinations will be implemented with 
some degree of coordination and congruence. 

The beginnings of true integrated network manage¬ 
ment were seen in 1992 with management of SNA, 
TCP/IP, and OSI networks and attached systems by 
NetView/390, AIX NetView/6000, AIX NetView 
Service Point, Systems Monitor/6000, LANfocus 
Management/2, LAN Network Manager, and LAN 
Management Utilities. It is not clear how these prod¬ 
ucts will relate to each other, and it may never be. 

IBM has made an impressive array of alliances and 
cooperative development agreements and, through 
them, has announced viable products in market areas 
that are not its traditional strength. Cooperative devel¬ 
opment is revolutionary for IBM and can assist the 
company in moving aggressively into new markets. 

We consider 1992 the year of “SNA and...,” that is, 
SNA as it relates to the world around it: SNA and 
TCP/IP, SNA and OSI, SNA and frame relay, SNA 
and multiprotocol routers, subarea SNA and APPN, 
SNA and Ethernet, SNA and NetBIOS, SNA and 
sockets, and even APPN SNA and openness. ■ 
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(continued from page 1) 


APPN 

This year will be as full of APPN news as 1992 was. 
We have a somewhat clearer view of 1993 direc¬ 
tions, though, because of the many statements of 
direction IBM has made about APPN, which are 
listed in Table 1 (see page 15). 

Three Types of Routing 

SNA Perspective believes that APPN will emerge in 
1993 with three possibilities for communication. 

Intermediate Session Routing (ISR). Existing 
APPN’s routing protocol is ISR. It uses a connec¬ 
tion-oriented network protocol and requires both 
layers 3 and 4 in each intennediate node. ISR does 
hot support adaptive routing in case of congestion or 
link failure. 

High-Performance Routing (HPR). IBM has 
begun to discuss some details about what has been 
called APPN+, a forthcoming version of APPN. 
APPN+ will include an alternative to ISR is called 
high-performance routing (HPR). APPN+ HPR will 
have separate layer 3 and 4 protocols. With HPR, 
the intermediate nodes can use only layer 3, similar 
to most protocol stacks such as TCP/IP. The net¬ 
work protocol in HPR will be connectionless. HPR 
will also support adaptive routing and will be imple¬ 
mented on several more link types. HPR will not be 
incompatible with existing APPN nodes using ISR; 
HPR nodes will also include the capability to appear 
as an ISR node. We expect that IBM will formally 
announce products with HPR in the first half of 
1993 and HPR for VTAM after the first half. • 

Connection Networks. The third type of APPN 
routing is connection networks. Connection net¬ 
works is a feature of APPN developed for LAN 
internetworks so end nodes can connect with just 
one APPN hop rather than using APPN hop-by-hop 
routing. 

APPN connection network support allows an APPN 
end node to define its connection to a LAN as one 
virtual routing node rather than to define its connec¬ 
tions to every other node on the LAN. A connection 


network can also be defined to include multiple 
bridged LANs and extend across WANs. 

Two end nodes defined on the same connection net¬ 
work can be connected to each other by a network 
node server as just one APPN hop, with the underly¬ 
ing bridge/router network treated as a shared access 
transport facility, rather than using APPN hop-by- 
hop routing. To APPN, the connection appears as a 
single hop rather than multiple hops from end node 
to network node, from network node to however 
many intervening network nodes, and then from the 
final network node to end node. Thus connection 
networks Can provide higher performance by avoid¬ 
ing APPN processing of each packet at every node. 

Connection networks will be part of the 6611 APPN 
and of the initial licensed APPN network node code. 
VTAM 4.1 can support connection networks as a 
network node, but we will have to wait for a future 
release for a VTAM end node to be able to be part 
of a connection network. 

Dependent LUs on APPN 

IBM’s strategic approach tor supporting dependent 
LUs over APPN has two steps. The first step, imple¬ 
mented in VTAM 4.1, allows LU 0, I, 2, and 3 traf¬ 
fic from all existing IBM and nonIBM peripheral 
SNA nodes to travel across an APPN network as 
long as the node remains logically adjacent to its 
boundary function (host or communication con¬ 
troller). VTAM 4.1 will ship in the first half of 1993. 

dLS/R. The second step in IBM's strategic 
approach is called the dependent LU server/ 
requester (dLS/R) model. A future release of 
VTAM will support dLS and a future release of 
3174 code will support dLR. dLS/R eliminates the 
adjacent boundary function requirement in VTAM 
4.1. Either the dependent LU can connect to an 
APPN network at any node with dLR or dLR can be 
added to the dependent LU node itself. 

We expect dLS to be part of VTAM 4.2 which will 
probably be announced in 1993 and shipped in early 
1994. We hope that IBM will make dLR specifica¬ 
tions available to other vendors so that their con¬ 
trollers, routers, and gateways can have dLR support 
by the time VTAM with dLS ships. 
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Encapsulation. IBM and several third parties are 
also discussing the development of encapsulated 
support for dependent LUs over APPN. This could 
be done in several ways—-tunneling, spoofing, or 
appc3270. Since these development efforts are in 
their early stages, SNA Perspective does not expect 
any encapsulation solutions to be available until the 
end of 1993. 

dLS/R will scale up to larger networks, mixed sub- 
area APPN networks, and very high-speed networks 
better than encapsulation, and will provide for more 
flexible and dynamic configurations for dependent 
LUs. However, dLS is VTAM dependent, requiring 
a future VTAM release at the dLS node as well as 
requiring VTAM 4.1 at most application nodes. 

APPN: Make or Break 

1993 is a make or break year for APPN. IBM must 
educate its subarea SNA customers on the ease of 
transition to APPN. The company must also deal 
with the significant TCP/IP momentum by making 
clear the benefits of APPN compared to TCP/IP. 
Finally, the company must deliver on products out¬ 
lined in the networking blueprint which allow 
smooth support for applications to communicate 
over a range of transports. APPN might be the nat¬ 
ural child of subarea SNA, but TCP/IP is also being 
“adopted” and stands to inherit a significant portion 
of the subarea SNA estate. 

How open must APPN be? IBM is agonizing over 
the different levels of openness available: published 
interfaces, source code licensing, published specifi¬ 
cations, free or nominal fee patent rights, published 
development plans, open industry development and 
participation, and open ownership. 

IBM took several significant steps toward APPN 
openness in 1992. IBM has published the APPN 
end node specifications and several interfaces and 
has said it will publish the network node specifica¬ 
tions. The company is also licensing source code 
and proposing several APPN elements to standards 
bodies. 


However, as pointed out by the APPI Forum (see 
discussion on page 17), IBM still owns APPN. 
Implementors can be required to pay patent license 
fees up front or for each copy even if they develop 
their own code. IBM also controls the develop¬ 
ment—it will develop the features and products it 
believes it can sell to the most users and afterward 
will publish the specifications for these new features. 

IBM is struggling to decide the appropriate price 
points and level of openness for APPN. This is a 
several billion dollar decision. We expect clear 
pricing and some additional movement on openness 
in 1993. 


LAN/WAN Integration 

Evolution of the Controllers 

IBM’s primary networking platforms are the 3745, 
3174, and 3172 (though the 6611 and PS/2 serve in 
this role as well). There has been much speculation 
that these three product lines may be succeeded by 
some other networking direction or family of prod¬ 
ucts. If this convergence of product lines into a new 
family is coming, it is unlikely to be announced 
until sometime in 1994. 

In the meantime, IBM has stated strongly through 
the evolution of these machines that they remain 
valid components of its multiprotocol network strat¬ 
egy. Though network protocols have evolved into 
peer-to-peer architecture, these existing products 
participate in the evolution. 

SNA Perspective believes that IBM will continue to 
support these platfonns well into the future in the 
company’s multiprotocol strategy for both LANs 
and WANs. All of these products play a role in the 
important LAN-mainframe market, which will be 
the subject of an upcoming SNA Perspective article. 

3745. During 1993, we expect IBM to support the 
ESCON adapter and enhanced token ring adapter of 
the 3746-900 on the 3745-170. 
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3172. On the 3172, we expect support for multiple 
protocols on a single adapter, SNMP network man¬ 
agement in TCP/IP Offload, additional OEM deals 
(in addition to AT&T and Bus-Tech), and ESCON 
support for LAN-channel configurations. 

3174. For the 3174, we expect the Ethernet adapter 
and additional TCP/IP support to ship by the end of 
the year. In 1992, we began to anticipate Ethernet 
for the 3174 as its TCP/IP features increased. 

Where TCP/IP is growing, could Ethernet be far 
behind? In September 1992, IBM announced that it 
intends to make the 3174 capable of attachment to 
Ethernet networks, both as a downstream node and 
as an upstream gateway. Although this enhance¬ 
ment by IBM is overdue, it is nonetheless welcome. 

Frame Relay 

Especially for SNA traffic, we expect 1993 to be a 
significant year for frame relay at IBM. We expect 
peripheral, subarea, and APPN SNA traffic over 
frame relay will be supported on the 
RouteXpander/2, 6611, 3174, and 3745. 

Multiprotocol Integration 

TCP/IP has been growing at an incredible rate in 
corporations with large SNA networks. IBM has 
been investing heavily in TCP/IP—with a major 
acceleration since 1991. The result has been an 
increasing array of products, a shorter design-to- 
shipment cycle, better integration with SNA and 
network management, and continued enhancements 
and additional features on existing products. 

The company will increasingly decouple applica¬ 
tions from networking for each stack so that cus¬ 
tomers can select applications and networks inde¬ 
pendently. We believe that IBM will continue to 
focus on greater integration of TCP/IP features with 
host resources. 

TCP/IP and SNA environments will increasingly 
coexist on networks and within systems and new 
applications will draw on the strengths of each. SNA 
Perspective expects increasing integration of SNA 
and TCP/IP, over wide area networks, metropolitan 
area networks, and local area networks during 1993. 


APPN Statements of 
Direction 

VTAM APPN border node in VTAM. Border 
node allows cross-network APPN connections. 

APPN session routing over channel-to-channel 
links. 

APPN session routing over SNA subarea 
routes. Currently, APPN can be routed only 
overtype 2.1 links. 

Dependent LU server/requester (dLS/R) in 
VTAM and 3174, respectively, for LU types 0, 

1, 2, and 3 support across APPN. 

APPN end node and network node as well as a 
CPI-C interface for AIX SNA Services/6000. 

Network management through NetView for 
APPN. Support will include dynamic collection 
and display of APPN network topology, existing 
remote operator controls applied to APPN 
resources, and collection facility, for APPC 
accounting data. 

APPN on NetWare. A joint development by IBM 
and Novell will implement APPN in NetWare for 
SAA. 

Mixed-media multilink APPN transmission 
groups. NCP 6.2 is expected to support these 
for APPN as well as subarea SNA links. 

Connection networks in VTAM. Connection net¬ 
works is an APPN feature which allows end 
nodes to define their connection to a LAN or 
internetworked LAN as a single virtual routing 
node and thus connect to each other over the 
entire LAN as a single APPN hop. 

TCP/IP over APPC/APPN (SNAckets). IBM will 
offer support for applications written to sockets, 
which usually run over TCP/IP networks, to run 
instead over APPC/APPN. 

6611 network node to VTAM/NCP composite 
network node through frame relay. 

SNA peripheral device, such as 3174, to 
VTAM/NCP composite network node over frame 
relay for APPN or peripheral SNA traffic. 
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Evolution of the Networking Blueprint 
An important element of the networicing blueprint is 
the common transport semantics, an interface that 
rides on top of the transport layer. Common transport 
semantics will be based in large part on IBM’s mul¬ 
tiprotocol transport networking (MPTN). IBM pub¬ 
lished MPTN in 1991 and has proposed it to 
X/Open for adoption as an industry specification. 
MPTN is a coordinated means of mapping, compen¬ 
sation, and address resolution between SNA, 

TCP/IP, OSI, and NetBIOS. 

SNA Perspective expects that, starting in early 1993, 
IBM will develop several MPTN-based products, 
primarily for communication between SNA and 
TCP/IP networks. These would support dependent 
and independent LUs in APPC across TCP/IP and 
sockets applications across SNA. 

The IBM networking blueprint extends to users 
beset by complex and costly networking choices the 
promise of enabling the coherent coexistence of 
compound solutions in a way that also reduces costs. 


APPN Network Management 

SNA Perspective believes that the major issue with 
network management is that now, with APPN capa¬ 
bility on workstations and midrange departmental 
processors, users have access to highly dynamic 
SNA network environments. The problem is that, 
although there is much APPN dynamism on the net¬ 
work, the host’s network management is static. 

However, IBM has already developed an 
SNA/APPN-specific successor to the network man¬ 
agement vector transport (NMVT) called the mul¬ 
tidomain support message unit (MDSMU). 

MDSMU provides network management functions 
in an APPN-only network where a network node 
can actually function as a focal point. 

We believe that IBM’s strategic solution to network 
management will not be based on SNA Management 


Services (SNA/MS). APPN network management 
and multiprotocol network management will likely 
be based on CMIP and SNMP even with the intro¬ 
duction of the MDSMU. CMIP is a more strategic, 
long-term direction for IBM, and it is integral to 
System View. APPN and multiprotocol network 
management will be able to be managed by 
NetView/390, which supports various architectures, 
including TCP/IP and SNMP, but the management 
will not be based on SNA/MS. 

The first release of the APPN source code will 
include an SNMP Management Information Base 
(MIB) so it can be managed by SNMP. 

Multiprotocol Network Management 

IBM has been providing Net View-based functions 
for integrated SNA, TCP/IP, and OSI networks 
being managed with SNMP and CMIP as well as 
IBM’s proprietary management protocols. We 
expect additional such features for NetView in 
1993. 

Standards-based network management allows for 
multiprotocol, multiplatform, multimedia network 
management. IBM customers want network man¬ 
agement for all of their systems and networks. IBM 
will start shipping the LANfocus Management/2 
family in 1993 and will continue to enhance AIX 
NetView/6000 for this purpose, as well as enhanc¬ 
ing their interface with NetView/390. 

The average time it takes to bring up a NetView/390 
focal point in a host in the SNA environment, from 
scratch, is about 400 person hours. In contrast, the 
average time it takes to activate AIX Net View/6000 
in the SNMP environment, from scratch to full func¬ 
tionality, is about fifteen minutes. This is an exam¬ 
ple of user benefits of a less complex system. 

SNA Perspective expects that NetView focal point 
logic will be found outside the hub—i.e., outside the 
S/370/390 environment. In fact, it will probably be 
found right on LANs within the workstation plat¬ 
form. LANfocus Managcmcnt/2 will evolve to be 
able to manage both SNA/MS focal point and 
NetView focal point. 


Network Management 
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Alliances 

With the breadth and depth of the information and 
communications industry, IBM could not be all 
things to all people even at its largest. With its sig¬ 
nificance workforce reductions of the past several 
years, and with another 25,000 jobs to be cut in 
1993, IBM cannot go it alone to provide the solu¬ 
tions its customers need. Over the past decade, IBM 
has increasingly taken on partners and alliances to 
fill out its offerings. Further, IBM has always been 
heavily involved in industry standards forums. 

We only touch on three important relationships for 
1993: Novell, the CPI-C Implementor’s Workshop, 
and the APPI Forum. 

Novell 

The IBM-Novell relationship is actually a set of 
evolving relationships. Novell seems to be a much 
greater beneficiary of that relationship than IBM, 
particularly with IBM’s offer of APPN network 
node. It appears that, since IBM is quite eager for 
APPN to be supported in NetWare but Novell has 
limited SNA expertise, the “joint development” of. 
APPN on NetWare will probably be primarily an 
IBM development effort. 

With IBM’s recent announcements for OS/2 LAN 
Server, the set of new functions is somewhat compa¬ 
rable to NetWare for SAA. 

NetWare is also appearing on the 3172. At Interop 
in October, IBM announced that Bus-Tech, a lead¬ 
ing manufacturer of LAN-to-mainframe—particu¬ 
larly Ethernet to mainframe—devices, will be using 
the IBM 3172 and running Novell NetWare for SAA 
as the operating system. Bus-Tech has been a lead¬ 
ing competitor for the 3172 even though it's products 
have mostly been TPC/IP-over-Ethcmet-to-main- 
frame rather than multiprotocol, multi-LAN-to- 
mainframe. This is another instance of IBM recog¬ 
nizing the importance of the NetWare installed base. 

CPI-C Implementor’s Workshop 

IBM is opening CPI-C to development participation 
by other vendors, though in a workshop under its 


own auspices. The first meeting was held in 
December 1992 and further meetings will be held in 
1993. IBM’s ability to open CPI-C was enhanced 
because a version of CPI-C is already an X/Open 
specification and because LU 6.2/APPC and the 
OSI transaction processing protocol standard, which 
can both run under CPI-C, are quite similar. 

CPI-C went through several changes in 1992, espe¬ 
cially in the area of openness. In 1992, IBM elimi¬ 
nated any license charges for developers using 
CPI-C. IBM had proposed CPI-C to X/Open as an 
interface specification. It was accepted with several 
changes such as nonblocking, accept multiple, secu¬ 
rity, and data conversion. IBM will be incorporat¬ 
ing these changes. To do so, IBM has started to 
number CPI-C levels. CPI-C 1.1 is the initial CPI-C 
with resource recovery. CPI-C with the X/Open 
extensions is referred to as X/Open CPI-C. CPI-C 
1.2 is the integration of CPI-C 1,1 and X/Open 
CPI-C. 

CPI-C level 2 will emerge in 1993, with Open 
Software Foundation Distributed Communication 
Environment extensions for directory services and 
. Kerberos security and additional multiprotocol sup¬ 
port for OSI transaction processing, TCP/IP trans¬ 
port, and full duplex APPC. 

We shall see in 1993 whether the industry partici¬ 
pants will feel like equal players when the game is 
played in IBM’s backyard. 

The APPI Forum 

As discussed in the “SNA in Perspective” article in 
this issue and in "APPI: the Product and the 
Protest” in December 1992, the APPI Forum was 
formed in August 1992 to support APPN end nodes 
and network nodes over TCP/IP, using routing and 
topology protocols and directory services based on 
TCP/IP instead of APPN. The Forum cites techni¬ 
cal, price, openness, and pervasiveness advantages 
of TCP/IP over APPN as well as the benefits of a 
single backbone protocol instead of multiprotocol 
backbones or tunneling. 

(continued on page 20) 
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Architect’s Corner 


♦ High-speed networking environment. Anew 
standard to the desktop is being proposed— 
100 megabit/sec Ethernet (802.3). Gigabit 
networking is on the horizon. The high speed 
requirement will impose change on the SNA 
protocols. 


Plumbing Paradigm Problems With the Plumbing 

is Obsolete Paradi9m 


by Dr. John R. Pickens 

Since the 1970s, the paradigm for networking has 
been plumbing. An infrastructure to transport data 
regardless of origin, destination, or type of data. 

In that sense, 1993 is shaping up as a year of fulfill¬ 
ment—though with hints of change. 

• U.S. political environment. A new presidential 
administration is on hand with a heavy 
emphasis to be placed on building a 
telecommunications infrastructure. 

• User environment. A widespread rollout of 
multimedia is underway. My local electronics 
stores now have row upon row of multimedia 
kits stacked in the aisles for the holiday 
season—and reportedly they are selling well. 
Networked multimedia cannot be far behind. 
The relationship of networked multimedia to 
operating system services such as Windows 
Dynamic Data Exchange still requires 
definition. 

• LAN environment. The triple standard is nearly 
pervasive—Ethernet 802.3, token ring 802.5, 
and FDDI. 

• SNA environment, APPN has moved fronvthe 
early beachheads of minicomputers (AS/400) 
and personal computers (PC) to the center of 
mainframes (VTAM) and routers (6611, third 
parties), with the integration of 3270 devices 
about to occur. 


There are two problems with the plumbing paradigm. 

First, all the pipes don’t fit together. There are SNA 
pipes, IPX pipes, and TCP/IP pipes. There are even 
pipes that are generic but spring leaks in times of 
flood (i.e., bridges and multicasting). 

Each of these independent pipe infrastructures has 
its own types of fittings and management methods. 
Various techniques have been proposed to carry 
pipes inside of pipes (tunneling) or incorporate 
special adaptation connectors (gateways). But 
each of these techniques results in reduced flow,- 
loss of manageability, or other problems with loss 
of function. 


Our Challenge 

We just need to design one type of pipe that sup¬ 
ports them all, right? 

For integrated multiprotocol routing (i.e., a single 
plumbing infrastructure) throughout the 1990s, 
many standards will be offered and many standards 
will fall. This prediction has been based upon con¬ 
siderations of the overwhelming complexity and 
scale of the network plumbing problem and the 
immense diversity and number of inwardly focused 
and outwardly contentious standardization environ¬ 
ments (vendor, de facto, ISO, IETF). 

But there is a more serious problem. Plumbing is no 
longer the correct paradigm! 
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First case in point, NetBIOS. NetBIOS carries 
data—yes, plumbing. But it also contains a distrib¬ 
uted name registration and discovery function. This 
function is used by operating system assisted func¬ 
tions—client server computing—a form of distrib¬ 
uted process model (albeit a weak model, inasmuch 
as use of NetBIOS names 
by the operating system is 
really not mandated). 


Advocates of this approach argue that it completely 
hides the communications (i.e., plumbing) abstrac¬ 
tion from the user—APIs, elements of procedure, 
everything. It also allows over twenty years of 
research in virtual paging systems experience to be 
applied to networking. 


Second, IPX. IPX carries 
data—yes, plumbing. But 
it also contains a multi - 
cast-based service regis¬ 
tration and discovery 
function—service access points (SAPs). SAPs are 
used by the operating system to enable client-server 
relationships between distributed processes—a 
stronger model than NetBIOS. In fact, one of the 
more difficult challanges for vendors routing IPX is 
maintaining currency with the evolving multicast- 
oriented SAP service required by the evolving 
NetWare operating system. 

Third, APPC. APPC carries data—yes, plumbing. 
But it also contains an operating system-oriented 
function—flexible registration and discovery of LU 
names and transaction program names (current 
architecture needs a minor extension to support a 
generic TP name-to-LU name directory services 
function). Interestingly, the original architecture for 
LU 6.2 did not define the LU to be a “pipe.” Rather 
it was defined as a resource manager—an element 
of the operating system. 

Finally, gigabit networking research. Gigabit net¬ 
works do carry data—yes, plumbing. But a growing 
contingent of the.research community is proposing a 
very different model for gigabit networks. The net¬ 
work as a virtual memory store. The network han¬ 
dles page faults, locates memory segments, and 
even assists in the location and distribution of 
processes. 


The network is behaving 
more like an operating system 
than a system of pipes. 


Distributed naming 
servers, process mapping, 
page faults—this doesn’t 
sound like plumbing. 
What is the new 
paradigm? 


A New Paradigm— 

Exoskeletal Nervous Systems 

How about exoskeletal nervous systems? The 
synapses, fiber, and pathways which knit together a 
functioning organism. (Alternate proposals for the 
new paradigm are welcomed,..) Whatever the para¬ 
digm, the network is behaving more like an operat¬ 
ing system than a system of pipes. Its services— 
process registration, memory mapping, data access— 
are supportive of, and ancillary to, operating sys¬ 
tems. Operating systems also move data, so the 
plumbing paradigm is not incorrect, just insufficient. 

By modeling the APPC LU as a resource manager. 
IBM’s SNA architects got the new paradigm correct 
the first time. Members of the research community 
have seen this coming for some time. The vendor 
community, however, is still focused on design and 
delivery of the plumbing paradigm. A change of 
focus is needed on the role of the network as an 
extension to the operating system by vendors and 
standards communities alike. The plumbing 
paradigm is obsolete. ■ 
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(continued from page 17) 


We find that many of the APPI Forum’s points have 
merit. However, SNA Perspective finds several con¬ 
cerns with the proposed APPI design. For example, 
because it does not communicate with APPN net¬ 
work nodes, it will not support hosts that connect to 
LANs through 3745s nor AS/400s running PC 
Support/400. We believe that the actual APPI speci¬ 
fication, which is scheduled to be available by the 
middle of 1993, may differ significantly from its orig¬ 
inal concept, hopefully addressing these concerns. 

At the time the APPI Forum was formed, IBM was 
not publicly planning to publish the APPN network 
node specifications but, rather, to make network 


node available only through licensing the source 
code. IBM was responsive to significant industry 
pressure—including pressure from the APPI 
Forum—and announced in October that it would 
publish the APPN specifications at the same time as 
the licensed code becomes available—in the first 
quarter of 1993. 

Support for industry input into APPN development 
could be a next step in opening APPN. This could 
be accomplished if the focus of the APPI Forum 
could change or expand—though we do not see this 
as likely. Alternatively, the IBM APPC/APPN 
Platfonn Developer’s Conference could be evolved 
to incorporate such participation, along the lines of 
the CPI-C Implementor’s Workshop. ■ 
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